A virtual machine monitor (“VMM”) creates an environment that allows multiple operating systems to run simultaneously on the same computer hardware. In such an environment, applications written for different operating systems (e.g., Windows, Linux) can be run simultaneously on the same hardware.
Running an operating system on a VMM involves virtualizing one or more of the following types of hardware: memory, I/O devices, and CPU(s). CPUs and I/O devices can be virtualized in the traditional way: the hardware is configured to trap when an operating system (“OS”) executes a privileged instruction, and the VMM simulates the completion of that instruction to maintain the illusion that the operating system has sole control of the hardware.
Memory virtualization typically involves two levels of translation, virtual-to-physical translation, which is defined by the OS, and physical-to-machine translation, which is defined by the VMM.
Traditional operating systems employ an abstraction of memory called “virtual” memory. When the OS or application accesses a virtual address, that address is translated into a “physical” address to allow the access to reach the real memory present in hardware. This translation is typically managed by the OS, but performed on the fly by the CPU.
The translation may be performed by dividing virtual and physical memory up into chunks called “pages”. The OS defines the “virtual-to-physical” mapping, or V→P, that assigns a page of physical memory to hold the contents of a particular virtual page. This mapping usually takes the form of “page tables” containing “page table entries” (PTEs). Each PTE defines a mapping from a virtual page to a physical page (on some architectures, one PTE may map more than one page). The CPU maintains a cache of translations in a “translation lookaside buffer” or TLB. If a virtual address is accessed for which there is not a valid translation in the TLB, the appropriate PTE is read from the currently active page table (pointed to by the CPU's “page table base register”), and then loaded into the TLB. This fill operation upon a TLB miss can be performed in hardware on some architectures, or in software on others. Often, operating systems provide each of their processes (running applications) with a separate virtual address space, defining a separate virtual-to-physical mapping for each, and switching the virtual-to-physical mapping in effect when the OS changes the process that currently executes.
This virtual-to-physical translation alone suffices when the OS is not running on a VMM. However, when the OS is run on a VMM, the VMM maintains ultimate control over the use of the memory resources, and allows multiple operating systems to share the same pool of memory. To maintain this control, the VMM translates the OS's physical memory accesses into accesses to “machine” memory. Thus the physical memory is also employed as an abstraction, and the machine memory becomes the real memory hardware when the OS is run on a VMM. The VMM defines the “physical-to-machine” mapping, or P→M, and maintains control over the CPU's translation activities (e.g. by setting the page table base register, and/or handling TLB fills). The P→M mapping assigns a page of machine memory to each page of physical memory. Because most CPUs only have a single TLB, for performance reasons the VMM usually creates direct mappings of virtual pages to machine pages. The direct mapping can be created by composing dynamically the OS's V→P translations with the VMM's P→M translations. The VMM ensures that the TLB employs the composed V→M translations when translating virtual accesses.
When the OS runs without a VMM underneath, the term “physical memory” refers to the real memory present in hardware. When the OS runs on a VMM that virtualizes physical memory, the term “machine memory” refers to the real memory present hardware. This nomenclature is standard.
Traditional VMMs impose their physical-to-machine translation on the operating system from bootup to shutdown. Virtualizing physical memory adds overhead to the system. For example, dynamically composing the V→P translations with the P→M translations slows the OS's normal memory management. Overhead is also added by constantly trapping and simulating privileged instructions. This overhead can slow interrupt handling, increase the fraction of CPU bandwidth lost to software overhead, increase response time, and decrease perceived performance.
Since the VMM virtualizes the hardware from bootup to shutdown, overhead is incurred even while virtualization is not necessary (for example, when only a single OS instance is running on the hardware). Thus the VMM can add unnecessary overhead to the computer.
It would be desirable to reduce the unnecessary overhead of the VMM.